\chapter{\dicom 网络通讯和\dcmfourche 工具包}

\dicom 标准致力于构建医学影像的存储和传输规范\cite{plain:d5}。影像储存部分包含影像文件的内部结合、数据中心分级存储模式等内容。影像传输部分是建立在TCP/IP协议上，用以进行影像设备和存储设备，存储设备和工作站之间进行图像和非图像数据通讯的协议。

理解\dicom 通讯协议是构建\dicom \ to HTTP 代理的基础，只有在认清基本协议的基础上，才能完成提供HTTP 代理的工作。


\section{\dicom 网络通讯}
\dicom   通讯协议属于应用层协议，建立在TCP/IP协议的基础上\cite{plain:d7}。在协议中，每一个网络实体都是对等的，任何一个节点都可以向其他节点提供服务或请求服务。在实际的PACS系统中，一般有3类节点，分别是影像设备、归档存储设备和工作站，这些终端设备基于\dicom 通讯协议传送医学检查数据，替代了原有的申请单、胶片和纸质检查报告在医疗机构内的传递和流转。

\dicom 网络通讯协议可以细分为CECHO、CFIND、CMOVE、CGET、CSTORE等服务协议，每种服务都有不同的用途，但是都基于相同的链接建立方式，使用相同的数据格式。
在开始为移动应用设计\dicom \ to HTTP 代理之前，首先I需要介绍\dicom 标准中的这些基本概念以及规则和流程。\cite{plain:d2}因为了解传统\dicom 网络通讯中的具体细节要点是实现面向移动设备的\dicom 应用服务的重要基础。另外也必须看到，移动终端设备不同于传统工作站，很多基础层面的概念和规则如果不进行调整，将会产生很多意想不到的问题。


\section{唯一标识符(UID)}
UID的定义基于ISO8824和ISO9834-3,被保证具有每个标识的全球唯一性，使用了下面的字符串产生机制:

\begin{equation}
UID=<\text{组织代码}>.<\text{后缀}>
\end{equation}

组织代码：是由权威部门维护发布的代表各个组织机构的标识代码，保证全球唯一。

后缀：是机构单位根据实际应用自行生成的，需保证在本组织内的唯一性\cite{plain:d4}。

\rule{0pt}{0pt} 

UID有以下几个编码规则:

\begin{enumerate}
\item 各个分量之间用‘.’分割
\item 每个分量必须是一个数，除了0以外，不能以0作为第一个数字
\item 如果整个UID字符串长度为奇个数字节，要在最后一个组成分量的末尾添加一
个NULL字符，使每一个UID字符串的总长度都为偶数。
\item 整个UID字符串的总长度不能超过64个字符，包括各个分量的数字、分隔符以及填充字符。
\end{enumerate}


例如：

\begin{equation*}
UID = <\text{组织代码}>.<\text{后缀}>=\uid{1.2.840.******.3.152.235.2.12.187636473}
\end{equation*}
\begin{equation*}
\text{其中: }\text{组织代码}=\uid{1.2.840.******},\text{后缀}=\uid{3.152.235.2.12.187636473}
\end{equation*}

\dicom 标准中使用了UID对网络环境中的各种消息信息进行统一编码。如:

\begin{table}[H]
%\caption{}
\centering
\begin{tabular}{p{5cm}p{8cm}}
\hline
\uid{1.2.840.10008.1.1} & 表示验证服务类(Verification SOP Class) \\
\uid{1.2.840.10008.1.2} & 表示默认的隐式VR小字头传输语法(Implicit VR Endian:Default Transfer Syntax)\\
\uid{1.2.840.10008.5.1.4.1.1.2} & 表示CT图像(CT Image Storage) \\
\hline
\end{tabular}%
\end{table}

\section{传输语法(Transfer Syntax)}
\label{sec:ts}

传输语法用来配置进行\dicom 网络通讯时的数据编码方式，共有是否省略VR(数据类型说明编码),多字节数据的字节序和是否需要压缩三个参数需要在创建连接时进行协商。\cite{plain:d1}

VR可以用来说明数据单元中的数据类型，如数字、字符串、UID等，在网络通讯时是否需要VR信息，可以在连接建立时指定相应的传输语法。

在不同的系统中，有对多字节数据的存储格式有从高位到低位(Big Endian)和从低位到高位(Little Endian)两种方式。如果网络中正好有两种不同存储方式的终端设备，彼此之间的数据传输造成差错。所以需要在连接建立时，确定一致的多字节数据传输格式，来保证数据通讯的正常。

另外可以在网络连接建立时，选择是否需要对数据进行压缩，如果需要压缩，还可以选择压缩格式。

在\dicom 标准中定义了一系列表示传输语法的UID，每个UID代表了一种\dicom 网络连接建立方式，常见的传输语法UID在表\ref{tab:ts}中列出。\cite{plain:d12}

\begin{longtable}{lp{4.5cm}p{5cm}}
	\caption{常见传输语法} \label{tab:ts}\\
		%\label{tab:ts} \\
	\multicolumn{3}{c}{Table \ref{tab:ts} Common UID of Abstract Syntax}\\
	%\label{tab:ts} \\
\hline
UID & 说明 &	名称 \\
\endfirsthead
\multicolumn{3}{l}{(续表\ref{tab:ts})}  \\
\hline
UID & 说明 &	名称 \\
\hline
\endhead
\hline
\multicolumn{3}{l}{\itshape 接下一页} \\
\endfoot

\endlastfoot
\hline
\uid{1.2.840.10008.1.2} &   隐式VR小字头不压缩(默认)& Implicit VR Little Endian(Default) \\
\hline
\uid{1.2.840.10008.1.2.1} & 显示VR小字头不压缩 & Explicit VR Little Endian\\
\hline
\uid{1.2.840.10008.1.2.1.99} & 压缩的显示VR大字头& 	Deflated Explicit VR Big Endian \\
\hline
\uid{1.2.840.10008.1.2.2} & 显示VR大字头不压缩 & 	Explicit VR Big Endian \\
\hline
\uid{1.2.840.10008.1.2.4.50} & 默认的8位JPEG Lossy编码图像传输语法 & 	JPEG Baseline (Process 1):Default Transfer Syntax for Lossy JPEG 8-bit Image Compression \\
\hline
\uid{1.2.840.10008.1.2.4.51} &  默认的12位JPEG Lossy编码图像传输语法 & 		JPEG Baseline (Processes 2 \& 4):Default Transfer Syntax for Lossy JPEG 12-bit Image Compression(Process 4 only) \\
\hline
\uid{1.2.840.10008.1.2.4.57} & & JPEG Lossless, Nonhierarchical (Processes 14) \\
\hline
\uid{1.2.840.10008.1.2.4.70} & 默认的8位JPEG Lossless编码图像传输语法 & JPEG Lossless, Nonhierarchical, First- Order Prediction(Processes 14 [Selection Value 1]):Default Transfer Syntax for Lossless JPEG Image Compression \\
\hline
\uid{1.2.840.10008.1.2.4.80} & & 	JPEG-LS Lossless Image Compression \\
\hline
\uid{1.2.840.10008.1.2.4.81} & & JPEG-LS Lossy (Near-Lossless) Image Compression \\
\hline
%\bicaption{表}{常用传输语法UID}{Table}{Common UID of Transfer Syntax} \\
%\caption{常见传输语法}\\
%\multicolumn{3}{c}{Table \ref{tab:ts} Common UID of Abstract Syntax}\\
%\label{tab:ts} \\
\end{longtable}%


\section{抽象语法(Abstract Syntax)}

抽象语法描述了需要使用的服务对象对SOP(Service-Object Pair),在\dicom 标准使用UID来为各种SOP进行编码，常用的SOP在表\ref{tab:sop}中列出。抽象语法说明了此次请求的目的或者是所期望的数据。比如 CT Image Storage表示请求储存CT影像，Modality Worklist Information Model – FIND表示期望获取Worklist数据。\cite{plain:d11}

\begin{longtable}{lp{8cm}}
	\caption{常见抽象语法} 	\label{tab:sop} \\
	\multicolumn{2}{c}{Table \ref{tab:sop} Common UID of Transfer Syntax}\\

\hline
SOP UID & SOP 名称 \\
\endfirsthead
\multicolumn{2}{l}{(续表\ref{tab:sop})}  \\
\hline
SOP UID & SOP 名称 \\
\hline
\endhead
\hline
\multicolumn{2}{l}{\itshape 接下一页} \\
\endfoot

\endlastfoot

\hline
\uid{1.2.840.10008.1.1} & 	Verification SOP Class \\
\hline
\uid{1.2.840.10008.5.1.4.1.2.1.1} & Patient Root Query/Retrieve Information Model – FIND \\
\hline
\uid{1.2.840.10008.5.1.4.1.2.1.2} &	Patient Root Query/Retrieve Information Model – MOVE \\
\hline
\uid{1.2.840.10008.5.1.4.1.2.1.3} & Patient Root Query/Retrieve Information Model – GET \\
\hline
\uid{1.2.840.10008.5.1.4.1.2.2.1} & Study Root Query/Retrieve Information Model – FIND \\
\hline
\uid{1.2.840.10008.5.1.4.1.2.2.2} & Study Root Query/Retrieve Information Model – MOVE \\
\hline
\uid{1.2.840.10008.5.1.4.1.2.2.3} & Study Root Query/Retrieve Information Model – GET \\
\hline
\uid{1.2.840.10008.5.1.4.1.1.1} & CR Image Storage\\
\hline
\uid{1.2.840.10008.5.1.4.1.1.1.1} & 	Digital X-Ray Image Storage – for Presentation\\
\hline
\uid{1.2.840.10008.5.1.4.1.1.2} & CT Image Storage \\
\hline
\uid{1.2.840.10008.5.1.4.1.1.4} & 	MR Image Storage \\
\hline
\uid{1.2.840.10008.5.1.4.1.1.6.1} & Ultrasound Image Storage \\
\hline
\uid{1.2.840.10008.5.1.4.1.1.7} & 	Secondary Capture Image Storage \\
\hline
\uid{1.2.840.10008.5.1.4.31} & Modality Worklist Information Model – FIND \\
\hline
%\caption{常见抽象语法}\\
%\multicolumn{2}{c}{Table \ref{tab:sop} Common UID of Transfer Syntax}\\
%\label{tab:sop} \\
\end{longtable}%

\section{表示层上下文(Presentation Context)}

在\dicom 标准中定义表示层上下文由传输语法和抽象语法两部分组成，分别说明了本次网络通讯如何传输和要传输什么内容。图\ref{fig:StoragePresentationContext}为在Windows系统中通过Wireshark抓包软件，获得的一个表示层上下文。可以看到本次网络通讯的传输语法为隐式VR小字头并使用JPEG Lossess编码进行压缩，抽象语法为DR图像存放。\cite{plain:d17}

\begin{figure}[H]
%\bicaption[fig:StoragePresentationContext]{图}{表示层上下文示例}{Fig.}{Example of Presentation Context} 
\centering
\scalebox{0.5}{\includegraphics{StoragePresentationContext.png}}
%\bicaption{图}{表示层上下文示例}{Fig.}{Example of Presentation Context} 
\bicaption[fig:StoragePresentationContext]{图}{表示层上下文示例}{Fig.}{Example of Presentation Context} 
\end{figure}


\section{应用实体(Application Entity)}

应用实体表示网络环境中的\dicom 终端节点，可以为摄片设备、技术工作站、报告工作站、归档服务器及胶片打印机等。应用实体相互之间是对等的关系，每个节点在向其他节点请求服务的同时，也可以向其他节点提供服务。如报告工作站需要向归档服务器请求图像及检查数据，同时也要提供图像存储服务来接受归档服务器根据相应请求所提供的图像。一般的，将发起服务请求的AE称作SCU，将提供服务的AE称作SCP。图\ref{fig:normalDicomSeq}说明了普通\dicom 网络服务SCU和SCP之间的通讯协议流程。\cite{plain:d16}

\begin{figure}
%\bicaption[fig:normalDicomSeq]{图}{一般\dicom 网络服务请求流程}{Fig.}{Common process of apply \dicom \  network service} 
\centering
\scalebox{0.75}
{
\begin{tikzpicture}[node distance = 2cm, auto]
% Place nodes
\node [block] (scu){SCU};
\node [block,right=6.75cm of scu.east] (scp){SCP};

\node [wblock,below of=scu] (scuAssRQ) {连接建立请求};
\node [wblock,right=5cm of scuAssRQ.east] (scpAssAC) {连接建立应答};

\node [wblock,below of=scuAssRQ ] (scuSrvRQ) {Dicom服务请求(根据抽象语法)};
\node [wblock,right=5cm of scuSrvRQ.east] (scpSrvAC) {Dicom服务应答};

\node [wblock,below of=scuSrvRQ ] (scrRelRQ) {释放连接请求};
\node [wblock,right=5cm of scrRelRQ.east] (scrRelAC) {释放连接应答};
%edges
\draw[line] ( [yshift=0.25cm]scuAssRQ.east) --  node {A-ASSOCIATE-RQ} ([yshift=0.25cm]scpAssAC.west);
\draw[line] ( [yshift=-0.25cm]scpAssAC.west) -- node[below] {A-ASSOCIATE-AC} ([yshift=-0.25cm]scuAssRQ.east);

\draw[line] ( [yshift=0.25cm]scuSrvRQ.east) --  node {DICOM服务请求} ([yshift=0.25cm]scpSrvAC.west);
\draw[line] ( [yshift=-0.25cm]scpSrvAC.west) -- node[below] {DICOM服务响应} ([yshift=-0.25cm]scuSrvRQ.east);

\path[line] (scuSrvRQ) edge [loop left] node[right] {再次请求} ();
\draw[line] ( [yshift=0.25cm]scrRelRQ.east) --  node {A-RELEASE-RQ} ([yshift=0.25cm]scrRelAC.west);
\draw[line] ( [yshift=-0.25cm]scrRelAC.west) -- node[below] {A-RELEASE-AC} ([yshift=-0.25cm]scrRelRQ.east);

\end{tikzpicture}
}
\bicaption[fig:normalDicomSeq]{图}{一般\dicom 网络服务请求流程}{Fig.}{Common process of apply \dicom \  network service} 
%\label{fig:normalDicomSeq}
\end{figure}

就像在网络环境中使用计算机名(Hostname)来标识网络中的节点一样, 在\dicom 环境中使用应用实体名(Application Entity Title 缩写为AE Title)来标识\dicom 节点。AE Title 是一个长度不能超过16个字节的字符串。习惯上将发起连接请求的节点AE Title称作 Calling AE Title,应答连接请求的节点AE Title称为Called AE Title。 如果再次观察图\ref{fig:StoragePresentationContext},可以看出在此次通讯中 Calling AE Title 为 UniSightZa,Called AE Title 为 EBM\_SERVER。



在确定了本地网络参数，Calling AE Title,远程网络参数,Called AE Title，传输语法，抽象语法这些条件后，就可以构造\dicom 连接请求(A-ASSOCIATE-RQ)，进而建立\dicom 网络连接(Association)，开展相关业务应用。图\ref{fig:CreateAssociation}说明了从上述参数条件开始构造\dicom 网络连接的过程。



\begin{figure}
%\bicaption[fig:CreateAssociation]{图}{构造Association}{Fig.}{Construct Association} 
\centering
\scalebox{0.5}{\includegraphics{CreateAssociation.pdf}}
\bicaption[fig:CreateAssociation]{图}{构造Association}{Fig.}{Construct Association} 
%\label{fig:CreateAssociation}
\end{figure}

\section{\dcmfourche 工具包}
\dcmfourche 是一组为医疗卫生单位提供的开源应用和工具的集合。基于性能和稳定性的原因，使用Java编程语言进行开发(支持JDK1.4及以上版本)。

\dcmfourche 项目的核心部分是一个强壮的\dicom 标准实现。\dcmfourche-1.x 版本的 \dicom 工具集被使用在全世界的很多应用产品中，目前主要的版本为2.x系列，在1.x版本基础上为了提供性能和适应性的原因重新设计了底层架构。\footnote{来自\dcmfourche 官网说明}

DCM4CHEE是在\dcmfourche 基础之上，基于JBOSS应用服务器环境的开源\dicom 应用服务程序。提供了Web浏览(Web-based UI)、\dicom 图像存储(\dicom  \ Storage)、\dicom 信息查询(\dicom \ Query/Retrieve)、WADO服务、HL7服务、IHE服务和MPPS、MWL等大量\dicom 和相关标准的实现。DCM4CHEE在\dicom \ SCU开发过程中，可以作为一个很好的标准SCP，方便进行测试。

\dcmfourche 对\dicom 协议提供了不同层次的抽象。开发者既可以仅使用上层API专注于应用开发，也可以深入底层API进行性能敏感的编程开发。由于本项目侧重于移动端的应用，所以在后面示例代码中，主要使用\dcmfourche 提供的高层API，使得程序简练、突出重点应用逻辑。对\dcmfourche 的实际使用方法会在下文的具体例子中进行穿插说明。

\section{使用\dcmfourche 建立\dicom 网络连接}
\label{sec:CreateAssociation}

根据图\ref{fig:CreateAssociation}中的依赖关系，使用\dcmfourche 工具包，创建\dicom 连接对象的代码为:


\begin{lstlisting}[language=JAVA,caption=创建\javaclass{Association}]
static public Association connect(String remoteHost,int remotePort,
                                      String aeCalled,Device device)
    throws InterruptedException, GeneralSecurityException,
            IncompatibleConnectionException, IOException {
    String aeCalling = "DCM4CHE";
    int    localPort = 104;`\codecomment`
    //`设置本地网络参数`
    Connection localConn = new Connection();
    localConn.setPort(localPort);
    //`设置远程网络参数`
    Connection remoteConn = new Connection();
    remoteConn.setHostname(remoteHost);
    remoteConn.setPort(remotePort);
    //`创建本地AETitle`
    ApplicationEntity local = new ApplicationEntity(aeCalling);
    local.addConnection(localConn);
    //`创建远程AETitle`
    ApplicationEntity remote = new ApplicationEntity(aeCalled);
    remote.addConnection(remoteConn);
    //`创建连接请求`
    AAssociateRQ associateRQ = new AAssociateRQ();
    //`表示层上下文`
    PresentationContext presentationContext = 
    	new PresentationContext(1,UID.VerificationSOPClass`\codecomment`, IVR_LE_FIRST`\codecomment`);
    associateRQ.addPresentationContext(presentationContext);
    //`使device对象监听发送到本地AE的网络消息`
    device.addConnection(localConn);
    device.addApplicationEntity(local);
    //`执行连接两个AE的操作，如果成功则返回连接对象`
    return local.connect(remote,associateRQ);
}
\end{lstlisting}

\circletext{1}\quad \emph{为简化代码，直接赋值了本地AETilte和TCP端口，在实际应用中应该从配置参数中读取}

\circletext{2}\quad \emph{echo服务使用VerificationSOPClass UID作为抽象语法}

\circletext{3}\quad \emph{静态常量\javaobject{IVR\_LE\_FIRST}的定义如下，声明了三个支持的传输语法}

\begin{lstlisting}[language=JAVA,caption=定义\javaobject{IVR\_LE\_FIRST}]
protected static final String[] IVR_LE_FIRST = {
	UID.ImplicitVRLittleEndian,//`隐式VR小字头`
	UID.ExplicitVRLittleEndian, 
	UID.ExplicitVRBigEndian 
};
\end{lstlisting}

可以看到，上述代码中使用了远程网络地址、端口和远程AE Title及一个用来处理网络消息的\javaclass{Device} 类型实例来创建了一个\javaclass{Association}类型对象。\javaclass{Association} 类型作为对\dicom 网络连接的抽象，屏蔽掉了底层网络的操作，开发者只要使用其上的各种方法，就可以访问各种应用层面的DICOM服务。

\section{小结}

在本章中，首先介绍了\dicom 标准和\dicom 标准中的一些基本概念(更具体的内可以参考\dicom 标准中的相关部分 \cite{plain:dcmPart} )。理解\dicom 标准中的基本概念是很重要的，后面的讨论和开发都是围绕着这些名词展开的。然后介绍了\dcmfourche 第三方类库及如何使用\dcmfourche 如何和\dicom 服务器端建立网络连接并给出了连接建立过程图。建立\dicom  网络连接部分是整个系统的基础，后面的各项服务应用都是在此基础上展开并深入的。



%\clearpage


\chapter{移动应用环境对\dicom 应用的影响}

传统的\dicom 网络应用程序是面向工作站主机和有线网络环境的。对于移动终端环境来说，除了提供服务的服务器外，工作站和基础网络都发生了巨大的改变，出现了在原有环境中不曾遇见的问题，。这些问题中的任何一个都阻碍了原有的\dicom 应用程序向移动终端的迁移，只有一一了解并解决这些问题，才能实现为移动终端提供\dicom 临床应用。

\section{移动终端设备的硬件差别}

目前的移动设备硬件和桌面工作站比较起来，有很多不同或差距。对于\dicom 应用来说，在CPU性能，屏幕尺寸和操作方式上的差别尤为重要，在设计面向移动终端的\dicom 应用程序时，需要仔细研究这些问题，提出针对性处理方案，才能获得令人满意的效果。



\subsection{CPU性能差距}

\dicom 应用中有大量的图像处理操作，对处理器的性能较敏感。虽然移动处理器技术日新月异，高端型号接近入门级桌面处理器的水平，但是平均水平仍是大幅落后于台式芯片。对于一些低端产品，在运行复杂的图像处理操作时，会要求用户接受较长的无响应等待，甚至直接卡死宕机。所以对于处理性能不高的移动设备，考虑将一些计算量较大的工作由服务器进行分担运算，把最终结果回传到移动端设备上。

图\ref{fig:performenceCompare}为一个PNG格式图像转JPEG的测试，使用的是相同的Objective-C代码，可以从图中看出，X86处理器的性能几乎达到了ARM移动处理的4倍以上。
%arm=11.7069 x86=2.9024
\begin{figure}
%\bicaption[fig:performenceCompare]{图}{移动设备和桌面设备性能比较}{Fig.}{Compare the performance of mobile device and desktop device} 
	%\label{fig:performenceCompare}
\begin{tikzpicture}[domain=0:12]

\draw[->] (0,0) --(12,0) node[right] {时间(秒)};

\draw[dashed]   (11.7069,4) --(11.7069,0)node[below]{$11.71$};

\draw[dashed]  (2.9024,4)  -- (2.9024,0) node[below]{$2.90$};

\draw (0,1) --  (11.7069,1) --(11.7069,1.5) --(0,1.5);

\draw (0,2) --(2.9024,2) --(2.9024,2.5) --(0,2.5);

\draw[->] (0,0) --(0,4) node[above] {CPU};

\draw (0,1.25) node[left] {New iPad};

\draw (0,2.25) node[left] {Mac Book Air};

\end{tikzpicture}
\bicaption[fig:performenceCompare]{图}{移动设备和桌面设备性能比较}{Fig.}{Compare the performance of mobile device and desktop device}  
%\label{fig:performenceCompare}
\end{figure}

\subsection{与专业显示器的差别}

在桌面环境中，往往使用专业的医学显示器来显示\dicom 影像。这些专业设备具有很高的空间分辨率和较大的物理尺寸（见表\ref{tab:pmonitor}）,对临床医生作出正确的诊断起到了重要作用。如普通的单幅DX图像分辨率超过$1000\times 1000$,CT图像单幅分辨率为$512\times 512$，但是一般会进行$3\times 3$或$4\times  4$ 排列，实际需要$1536\times 1536$以上的分辨率。而移动设备的显示屏尺寸和分辨率相比之下就显得小了许多，不能直接套用传统的\dicom 应用程序的图像排列方式。

\begin{table}[H]
\bicaption[tab:pmonitor]{表}{专业显示器常见规格表}{Tab.}{Common profession display specification} 
\centering
\begin{tabular}{llll}
\hline
规格 & 尺寸 & 分辨率 &	像素间距 \\
\hline
2MP & 21.3英寸 &   $1600\times 1200$ & $0.270\times 0.270$mm \\
\hline
3MP & 20.8英寸 &   $2048\times 1536$ & $0.207\times 0.207$mm \\
\hline
5MP & 21.3英寸 &   $2560\times 2048$ & $0.165\times 0.165$mm \\
\hline
10MP & 30英寸 &   $4096\times 2560$ & $0.158\times 0.158$mm \\
\hline
\end{tabular}%
%\bicaption{表}{专业显示器常见规格表}{Tab.}{Common profession display specification} 
%\label{tab:pmonitor}
\end{table}

\begin{table}[H]
\bicaption[tab:mobilemonitor]{表}{常见移动设备显示屏规格}{Tab.}{Common display specification of mobile device} 
\centering
\begin{tabular}{llll}
\hline
 尺寸 & 分辨率 &	代表型号 \\
\hline 3.2英寸 &   $480\times 320$ & Motorola XT502  \\
\hline
3.7英寸 &   $800\times 480$ & Google Nexus One \\
\hline
 4.95英寸 &   $1920\times 1080$ & Google Nexus 5 \\
\hline
 10英寸 &   $2048\times 1536$ & Motorola XOOM \\
\hline
 3.5英寸 &   $480\times 320$ & Apple iPhone 3GS \\
\hline
 3.5英寸 &   $960\times 640$ & Apple iPhone 4S \\
\hline
 4英寸 &   $1136\times 640$ & Apple iPhone 5 \\
\hline
 9.7英寸 &   $1024\times 768$ & Apple iPad 2 \\
\hline
 9.7英寸 &   $2048\times 1536$ & Apple iPad 4 \\
\hline
\end{tabular}%
%\bicaption{表}{常见移动设备显示屏规格}{Tab.}{Common display specification of mobile device} 
%\label{tab:mobilemonitor}
\end{table}



\subsection{操作方式的改变}

在桌面环境下，主要通过鼠标和键盘进行交互操作。比如在图像浏览时，往往会定义鼠标左键拖拽进行调窗操作，右键拖拽进行亮度和对比度调整，滚动滚轮进行图像缩放或翻页
操作。但是移动设备普遍没有鼠标和键盘等外设支持，几乎全部操作都需要靠触摸屏幕来完成，所以需要改变控件大小和布局来适应较粗的手指的触碰点击，还需要定义一系列手势来取代不同的鼠标操作。

\subsection{移动设备系统的软件接口限制}

传统\dicom 网络通信基于TCP/IP协议，需要使用经典的BSD C Socket API。目前主流的桌面操作系统都提供了接口形似类似的Socket API，满足了\dicom 网络通讯的基本需要。比如在\dcmfourche 工具包中，就是通过使用Java SDK \ 包装后的Socket API进行网络编程。但是目前各种移动设备和移动操作系统平台对Socket API的支持程度差距较大，有些即便支持了，也有很大的局限性。比如在iOS 7.0以上环境不支持任何应用程序获得本机的Mac地址，也不支持使用任何1-1024之间的TCP端口号，而\dicom  协议默认的端口号为104，恰好在此范围内。Android系统平台也面临类似的问题。 所以，直接将现有的\dicom  应用程序迁移到移动平台上，要么是能不正常编译安装，即使能部署执行，也会出现网络不稳定的情况。

在存储方面，由于移动设备可用空间有限，对应用程序可使用的存储容量有严格的限制。传统的\dicom 应用程序为了提高性能减少带宽占用，往往将从SCP取得的图像文件在本地缓存，再次调用时就直接从本地读取，不再发生网络通讯。因为这种以空间换时间的方式，可以大大加快桌面工作站的运行效率，所以一般都是尽可能的设置较大容量的磁盘缓存(比如1GB-10GB)，以达到提高程序性能的目的。然而，与桌面工作站动辄1TB的磁盘容量相比，移动终端设备的总存储空间还在8GB-32GB之间徘徊，无法提供较大的空间用以图像缓存。另外，即便是如64GB或128GB版 iPad 这样大容量设备，由于Apple 公司严格的应用程序审核机制，这种几分钟内就可以占用100多MB的图像缓存策略是很难通过审批，供 App Store 销售的。

\section{无线网络造成的通讯问题}

在传统的\dicom 应用程序中，往往会有AE列表配置功能，此列表用来将一个AETitle和主机地址及端口联系起来。在需要建立网络连接时，直接选择目的AE Title即可，不用每次输入主机地址和端口。另外\dicom 中的CMove方法，需要SCU提供用以接收图像的AE Title，如果SCP端的AE列表中没有这个AE Title，将会返回SCU端未知AE错误。但是移动设备普遍使用无线网络设备，便携性高，可以方便的在不同的楼宇、院区间漫游。从网络拓扑层面上看，就是一个设备会在不同的子网范围内使用，很难规定每个设备的固定网络地址，从而造成无法在SCP端设置移动设备的AE，使得\dicom 应用不能正常使用。

而且，在移动网络中，一般都会部署防火墙设备并设置相应策略，来阻断未授权的访问，但是这些策略主要是针对像HTTP，FTP，SMTP这些常见互联网服务的，
对\dicom 协议的支持度不高，基本不能制定应用层面的安全策略。所以在需要较高安全性的无线环境中，传统的\dicom 网络协议很难方便灵活的设置网络安全策略。


\begin{figure}[H]
%\bicaption[fig:AESetting]{图}{DCM4CHEE应用服务器中的AE配置界面}{Fig.}{AE Setting UI of DCM4CHEE Application Server} 
\scalebox{0.65}{\includegraphics{AETitles.png}}
\centering
\bicaption[fig:AESetting]{图}{DCM4CHEE应用服务器中的AE配置界面}{Fig.}{AE Setting UI of DCM4CHEE Application Server} 
%\label{fig:AESetting}
\end{figure}

\section{应对方案}

通过上文的分析，开发移动端的\dicom 应用程序的主要工作是根据移动平台特点改变客户端人机交互方式和调整网络通讯方式。

对于移动客户端的交互方式改变的问题，需要重新就触摸屏的操作特点开发用户界面和操作方式。这项工作可以采用跨平台的HTML5方式，也可以采用各平台的原生API方式。考虑到基于HTML5方式可以实现的功能有限，在后面的开发中以原生API为主，对适用与HTML5方式的地方也会进行说。

对于通信传输部分，需要设计一个Http到\dicom 的代理服务器程序，来为移动应用程序提供Web 服务。因为移动设备操作系统平台对Http协议支持较好，使用Http这一无状态的传输协议，就不再需要对设备固定网络地址，也可以充分利用防火墙提供的应用层安全管理功，从而能规避掉使用传统TCP 方式的许多问题。图\ref{fig:httpProxy}是Http代理方案的示意图。

\begin{figure}[H]
%\bifigcaption{fig:httpProxy}{使用HTTP代理传统的\dicom 网络通讯}{Classical \dicom \ data  transmission over HTTP}
%	\label{fig:httpProxy}
\begin{tikzpicture}[node distance = 2cm, auto]
% Place nodes

\node [block] (scu){\dicom \ 移动应用};

\node [block,right=4cm of scu.east] (proxy){\dicom \ HTTP\ Proxy};

\node [block,right=4cm of proxy.east] (scp){经典 \dicom \ SCP};

%edges

\draw[line]([yshift=0.25cm]scu.east) -- node[above]{\zihao{6} HTTP协议，JSON数据} ([yshift=0.25cm]proxy.west);
\draw[line]([yshift=0.25cm]proxy.east)--node[above]{\zihao{6} TCP协议，二进制数据} ([yshift=0.25cm]scp.west);


\draw[line]([yshift=-0.25cm]proxy.west) -- node[below]{\zihao{6} HTTP协议，JSON数据} ([yshift=-0.25cm]scu.east);
\draw[line]([yshift=-0.25cm]scp.west)-- node[below]{\zihao{6} TCP协议，二进制数据} ([yshift=-0.25cm]proxy.east);
\end{tikzpicture}
\bifigcaption{fig:httpProxy}{使用HTTP代理传统的\dicom 网络通讯}{Classical \dicom \ data  transmission over HTTP}
%\label{fig:httpProxy}
\end{figure}

\dicom \ to Http 代理服务器和移动端应用之间使用JSON数据格式进行通讯交互，比传统\dicom 协议的TCP方式更加清晰明了，并且具体的数据格式内容说明会在后文详细说明。

对于性能不高的移动设备，在\dicom \ to Http 代理中也提供了获得JPEG图像格式文件等的途径，不需要在本地解析和渲染\dicom 格式文件，避免了进行大量图像格式转换运算，保证了客户端用户体验的流畅。

\section{小结}

本章就经典的\dicom 设备和网络环境和移动设备和网络环境进行比较，发现使用移动终端设备和移动网络环境下会产生许多过去所没有遇到的问题。在本章中说明了这些问题产生的原因，及所造成的影响，最后分析得出需要编写一个\dicom \ to HTTP Proxy Web服务来解决网络环境中的问题。通过本章的讨论，可以了解本项目的开发工作是要解决那些实际应用问题，以及为什么要使用HTTP代理来向移动平台提供\dicom 网络服务。